Last updated: August 21, 2000
|
|
|
|
|
|
|
|
1 General
Inet's Spectra system is used by the TelORB verification department to generate HLR and SCP traffic over the SS7 stacks, as one of the ways to put load on the TelORB system and to simulate a customer site. The Spectra system is quite often erroneously called "the Inet", but Inet Technologies, Inc. is the company that manufactures the Spectra product and is thus NOT the product name.
This document describes some ways of setting the Spectra system and the surrounding environment up in the TelORB lab at UAB.
In the instructions below, the TelORB zones to7 and to8 are used as reference zones. To7 and to8 are set up as a network redundant TelORB system.
Remember to substitute the "to7" and "to8" specific parts in these instructions with what is valid for the TelORB system that you are running. This is also valid for the IO processors, i.e. IO processor 1 is used as a reference in these instructions, but it is also possible to use IO processor 2, or a workstation for that matter.
The Spectra system, referred to in these instructions, is physically connected to the two SS7 interface boards situated in each of the TelORB zones (to7 and to8), see simplified figure below. This makes it possible to switch the traffic generation from one TelORB zone to the other.
It is not recommended to generate traffic to both zones simultaneously, due to network redundancy reasons.
=================== ===================
| TelORB zone to7 | | TelORB zone to8 |
| |-------------------------| |
| SS7:1 SS7:2 | Network redundancy | SS7:1 SS7:2 |
=================== link ===================
\ \ / /
\ \ / /
==================================================
| S p e c t r a |
==================================================
Populate with HLR subscribers
Omni (SS7) setup
Spectra setup
|
|
Population setup
|
3 Instructions
Populate HLR
rlogin to8io1
cd /opt/Populator/
ls -l
./man_metapop (Running this script takes approximately one hour)
Some explanations before setting Omni up
Omni consists of the SS7 HW in the TelORB cabinet (SS7 processor and link
boards)and also the SS7 SW. The SS7 SW runs on the SS7 processor boards.
To achieve a two-way communication between a workstation (WS) and the SS7
stacks, communication path(s), via one or both of the IO processors, has to be
set up. See simplified figure below.
====== ====== ======
| WS | | WS | | WS |
====== ====== ======
| | |
| | | Network (Pink LAN, net 184-187)
__________________________________________________________________________
| |
T | |
e ========= ========= ======= ======= =====================
l | SS7:1 | | SS7:2 | | IO1 | | IO2 | | TelORB processors |
O ========= ========= ======= ======= =====================
R | | | | |
B | | | | |
cabinet | | | | |
__________________________________________________________________________
Ethernet x 2
OMNI Distributed Filesystem
The OMNI SS7 stack are composed of two CPU boards referred to as two CEs
(Computing Elements). The two CEs work together and a redundant fashion
to provide the SS7 services.
To achieve redundancy, a Distributed Filesystem (DF) is used between the
two CEs. When logged on to any of the two CEs, one can see the normal
Unix file system and do all supported commands (ls, ps, mkdir, etc).
However, another and distinct filesystem also exists and has a small set
of commands. These special commands need to be used to be able to
access the DF filesystem. Note that the DF filesystem does not support
directories but only files.
DF commands:
===========
DFdir - list the contents of the DF filesystem
DFdir should list each DF file twice: one per CE.
If this is not the case, the DF filesystem has a problem
probably caused by a bad cross-mount between the two CEs.
DFcat - output the DF file to the screen
DFunlink - remove the DF file from the DF filesystem
DFconvert - add the unix file to the DF filesystem
These commands, combined with unix commands allow to do most everything
a user may need. The following are examples of useful combinations of
commands:
List the files containing the name cestart:
DFdir | grep cestart
Copy a DF file so we can change it:
DFcat cestart.344 > ./cestart.344
One can then edit the unix file ./cestart.344 (note that these changes
will NOT be in the DF file).
Copy a changed unix file to the DF filesystem:
DFconvert cestart.344
Note that the cestart.344 file must exist on you current unix directory.
This file will automatically be copied OVER the DF file called
cestart.344.
This means that before doing a DFconvert, you must have the file use the
correct name.
Remove a DF file that you don't want:
DFunlink rc.to8s71.344
Important DF files
==================
cestart.$SHM
$SHM is the current Shared Memory Number (usually 344)
File specifying all application processes and parameters running
tapdes.$SHM
Specifying which of the applicaiton processes are 'Designated'
db..sccp.$SHM.pri
is the shared name between the two CEs e.g., to7s7
File specifying all SCCP parameters e.g., Point-Code, Remote SSNs,...
db..mtp.$SHM.pri
File specifying all MTP parameters
e.g., Point-code, linksets, links, routesets,...
rc..$SHM
Recent Changes file. This file contains all the commands recently
given by the user for MTP and SCCP data. This file should be
empty most of the time. If it is not, the changes that need to
be kept should be manually put it db..sccp.$SHM.pri
and db..mtp.$SHM.pri, and then the rc file should
be DFunlink:ed.
Advanced
========
For the advanced user.
The DF filesystem actually stored the DF files in two unix directories
/export/home/omni//dffile and /export/home/omni//dffile.
One can play with these files when no other means are possible.
USE CAREFULLY.
--
Source: E-mail from Marc A. Khouzam, 991125.
Open new shell windows and name them
- Open a shell window from a WS that is connected to the Pink LAN network.
- From the opened shell window, open six new shell windows and name them as
described below (other names may of course be used):
cmdtool -Wl to7io1& (For IO processor in to7)
cmdtool -Wl to7s7c1& (For SS7 stack 1 (SS7:1) in to7) (c1=client 1)
cmdtool -Wl to7s7c2& (For SS7 stack 2 (SS7:2) in to7) (c2=client 2)
cmdtool -Wl to8io1& (For IO processor in to8)
cmdtool -Wl to8s7c1& (For SS7 stack 1 (SS7:1) in to8) (c1=client 1)
cmdtool -Wl to8s7c2& (For SS7 stack 2 (SS7:2) in to8) (c2=client 2)
Log in to SS7:1 on to7 via one of the IO processors from window to7s7c1
rlogin to7io1 -l telorb
psw:tel123orb
rlogin to7s7c1 -l omni
psw:omni123
Log in to SS7:2 on to7 via one of the IO processors from window to7s7c2
rlogin to7io1 -l telorb
psw:tel123orb
rlogin to7s7c2 -l omni
psw:omni123
Set up display connection from IO processor to WS from window to7io1
To be able to display what happens on the SS7 stacks on a WS, one has to go via
an IO processor. This is made possible by using the xmx script, which
displays everything that happens on the SS7 stack on a predefined IO processor
port to which a WS is listening. Any unused IO processor port can be used, and
in these instructions IO processor port 1111 has been selected.
- Set up xmx so that everything that happens on, in this case, IO port 1111 is
displayed on e.g. WS uabs31i1c46 which has IP address 134.138.186.46:
xmx :1111 -display uabs31i1c46:0
or
xmx :1111 -display 134.138.186.46
- Wait for the printout "-->XMX Version 1.1, ready".
Set up display connection from SS7:1 to IO processor from window to7s7c1
- Display everything that happens on the SS7 stack on e.g. IO port 1111:
setenv DISPLAY to7io1:1111
- Test the display connection all the way from the SS7 stack to the WS:
xlogo (An xlogo image should appear on the WS.)
Set up display connection from SS7:2 to IO processor from window to7s7c2
- Display everything that happens on the SS7 stack on e.g. IO port 1111:
setenv DISPLAY to7io1:1111
- Test the display connection all the way from the SS7 stack to the WS:
xlogo (An xlogo image should appear on the WS.)
Start omni from window to7s7c1
go.omni -slan n & (Omni windows should appear on the WS.)
- Wait for the printout "...state is running".
- Omni windows should appear on the WS.
Start omni from window to7s7c2
go.omni -slan n & (Omni windows should appear on the WS.)
- Wait for the printout "...state is running".
- Omni windows should appear on the WS.
Log in to SS7:1 on to8 via one of the IO processors from window to8s7c1
rlogin to8io1 -l telorb
psw:tel123orb
rlogin to8s7c1 -l omni
psw:omni123
Log in to SS7:2 on to8 via one of the IO processors from window to8s7c2
rlogin to8io1 -l telorb
psw:tel123orb
rlogin to8s7c2 -l omni
psw:omni123
Set up display connection from IO processor to WS from window to8io1
To be able to display what happens on the SS7 stacks on a WS, one has to go via
an IO processor. This is made possible by using the xmx script, which
displays everything that happens on the SS7 stack on a predefined IO processor
port to which a WS is listening. Any unused IO processor port can be used, and
in these instructions IO processor port 1112 has been selected.
- Set up xmx so that everything that happens on, in this case, IO port 1112 is
displayed on e.g. WS uabs31i1c46 which has IP address 134.138.186.46:
xmx :1112 -display uabs31i1c46:0
or
xmx :1112 -display 134.138.186.46
- Wait for the printout "-->XMX Version 1.1, ready".
Set up display connection from SS7:1 to IO processor from window to8s7c1
- Display everything that happens on the SS7 stack on e.g. IO port 1112:
setenv DISPLAY to8io1:1112
- Test the display connection all the way from the SS7 stack to the WS:
xlogo (An xlogo image should appear on the WS.)
Set up display connection from SS7:2 to IO processor from window to8s7c2
- Display everything that happens on the SS7 stack on e.g. IO port 1112:
setenv DISPLAY to8io1:1112
- Test the display connection all the way from the SS7 stack to the WS:
xlogo (An xlogo image should appear on the WS.)
Start omni from window to8s7c1
go.omni -slan n &
- Wait for the printout "...state is running".
- Omni windows should appear on the WS.
Start omni from window to8s7c2
go.omni -slan n & (Omni windows should appear on the WS.)
- Wait for the printout "...state is running".
- Omni windows should appear on the WS.
If you want explanations to the instructions in this subchapter, see previous
subchapter.
Be sure to substitute the TelORB zone names, IO processor names, WS
identities, etc. with what is valid for the TelORB system that you are running.
Open cmdtool windows
--------------------
rlogin to8io1
psw: tel123orb
setenv DISPLAY uabs31i1c50:0
cmdtool -Wl to8io1 &
cmdtool -Wl to8io1s7c1 &
cmdtool -Wl to8io1s7c2 &
rlogin to7io1
psw: tel123orb
setenv DISPLAY uabs31i1c50:0
cmdtool -Wl to7io1 &
cmdtool -Wl to7io1s7c1 &
cmdtool -Wl to7io1s7c2 &
Enter the following in cmdtool to8io1
-------------------------------------
xmx :1112 -display uabs31i1c50:0&
(Printout: -->XMX Version 1.1, ready)
Enter the following in cmdtool to8io1s7c1
-----------------------------------------
rlogin to8s7c1 -l omni
psw: omni123
Enter the following in cmdtool to8io1s7c2
-----------------------------------------
rlogin to8s7c2 -l omni
psw: omni123
Enter the following in cmdtool to8io1s7c1
-----------------------------------------
setenv DISPLAY to8io1:1112
(Test: xlogo)
go.omni -slan n &
(Printout: Reload complete board 0...state is RUNNING)
Enter the following in cmdtool to8io1s7c2
-----------------------------------------
setenv DISPLAY to8io1:1112
(Test: xlogo)
go.omni -slan n &
(Printout: Reload complete board 0...state is RUNNING)
Enter the following in cmdtool to7io1
-------------------------------------
xmx :1111 -display uabs31i1c50:0&
(Printout: -->XMX Version 1.1, ready)
Enter the following in cmdtool to7io1s7c1
-----------------------------------------
rlogin to7s7c1 -l omni
psw: omni123
Enter the following in cmdtool to7io1s7c2
-----------------------------------------
rlogin to7s7c2 -l omni
psw: omni123
Enter the following in cmdtool to7io1s7c1
-----------------------------------------
setenv DISPLAY to7io1:1111
(Test: xlogo)
go.omni -slan n &
(Printout: Reload complete board 0...state is RUNNING)
Enter the following in cmdtool to7io1s7c2
-----------------------------------------
setenv DISPLAY to7io1:1111
(Test: xlogo)
go.omni -slan n &
(Printout: Reload complete board 0...state is RUNNING)
Miscellaneous
-------------
Terminate 0 (Terminates go.omni)
Check link status
-----------------
... Network Control---> Link Status
(Should be green)
Open two shell windows to be used for the SS7 stacks.
In the first shell (for first SS7 stack):
rlogin to8io1 (Log in to IO as telorb user)
psw (Type password)
xmx :1111 -display 134.138.187.9 (1111 = any non-used port on IO)
(134.138.187.9 = IP address to WS toc4)
(xmx is a script that, in this case,
displays everything that happens on port
1111 on WS toc4 (134.138.187.9))
Ctrl-z
bg (Put xmx in background)
exit (Exit from IO so that the opened shell
will not be disturbed by xmx printouts)
rlogin to8io1 (Log in to IO as telorb user)
psw (Type password)
rlogin to8s7c1 -l omni (Log in to SS7 as omni user (c1=client 1))
omni123 (Type password for omni)
ps -ef (Check if omni is running)
Terminate 0 (Terminate omni. If omni is not running,
almost only the following printout is
received: "Terminate: FtRegisterEx() error
267 = nothing running"
setenv DISPLAY to8io1:1111 (Display on to8io1 port 1111 which is xmx:ed
to WS toc4)
go.omni -slan no (Start omni)
Check that the following line is received: "...state is running"
In the second shell (for second SS7 stack):
rlogin to8io2 (Log in to IO as telorb user)
psw (Type password)
rlogin to8s7c2 -l omni (Log in to SS7 as omni user (c1=client 1))
omni123 (Type password for omni)
ps -ef (Check if omni is running)
Terminate 0 (Terminate omni. If omni is not running,
almost only the following printout is
received: "Terminate: FtRegisterEx() error
267 = nothing running"
setenv DISPLAY to8io1:1111 (Display on to8io1 port 1111 which is xmx:ed
to WS toc4)
go.omni -slan no (Start omni)
Check that the following line is received: "...state is running"
Terminate Omni from window(s) to7s7c1, to7s7c2, to8s7c1 and/or to8s7c2
Terminate 0 (If omni is not running, almost only the following
printout is received: "Terminate: FtRegisterEx()
error 267 = nothing running")
General
Use the arrow keys to navigate in the Spectra menu system.
To back out from a window in the Spectra menu system, press the ESC key.
Log in to Spectra
Perform the following from the PC that is connected to the Spectra system, which
in its turn is connected to the TelORB system to generate traffic upon.
- Go to the C directory, i.e. C:\>.
- Type SPECTRA.
- Press F1 (Setup).
- Log in to Spectra:
Please Enter User Id : SYSADMIN
Please Enter Password: SYSADMIN
Select configuration
- Press F1 (Setup).
- Select RECALL CONFIGURATION and then select the desired configuration,
e.g. TO7_TO8. (`Select' always means mark and press the ENTER key.)
- Select APPLY CONFIGURATION.
Run tests
- Select MODE -> SS7 -> CVR TESTERS -> LEVEL 2 TESTER -> LINKSET 1.
- Press F2 (Run).
- Answer Y to the question "Restart test(Y/N):".
- Check that "Test Passed" is received.
- Press Esc, F1 (Setup), Esc, Esc.
- Select LEVEL 3 TESTER -> LINKSET 1.
- Press F2 (Run)..
- Answer Y to the question "Restart test(Y/N):".
- Check that "Test Passed" is received.
- Press Esc, F1 (Setup), Esc, Esc.
- Select TCAP TESTER -> LINKSET 1.
- Press F2 (Run).
- Answer Y to the question "Restart test(Y/N):".
- Check that "Test Passed" is received.
- Press Esc, F1 (Setup), Esc, Esc, Esc, Esc, Esc.
Select traffic model
- Select MODE -> SS7 -> TCAP GENERATOR -> LINKSET 1 -> TRAFFIC MODELS.
- Type R (Recall).
- Select e.g. STD_MIX.LMD.
- Esc, Esc, Esc, Esc, Esc, Esc.
Start traffic
- Press F2 (Run).
- Answer Y to the question "Restart test(Y/N):".
- Esc.
Check traffic
- Press F3 (Stats).
- Select SS7 Basic Stats.
- Toggle between the pages by using the up and down arrow keys.
(M = MasterReset)
Exit from Spectra
Press F1 (Setup).
Select EXIT TO DOS.
Configure Spectra
- Press F1 (Setup).
- Select CONFIGURE -> SS7 -> LEVEL 3 PARAMETERS -> NETWORK CONFIGURATION.
- Press C to assign Linksets:
LS1 LS2 LS3 LS4 LS5 ... L16
SP1 X X
SP2 X X
SP3
.
SP16 X X X
Press ENTER to define LingsetDefinition:
1 2 3 4 5 ... 16 (links)
1:LINKSET 1 0 <--SLC (Signaling Link Code)
2:LINKSET 2 0 <--SLC
3:LINKSET 3 0 <--SLC
4:LINKSET 4 0 <--SLC
5:LINKSET 5
:
16:LINKSET 16 4 ... 15
SP1 (10-10-1) LS1 LS3
SP2 (10-10-2) LS2 LS4
LS1 -> 226-255-47
LS3 -> 226-255-48
LS2 -> 226-255-47
LS4 -> 226-255-48
Point code for TO7: 226-555-47
Point code for TO8: 226-555-48
MESSAGE FILTER
--------------
- Select CONFIGURE -> SS7 -> FILTERS -> MESSAGE FILTER -> ON
SCCP:PASS
next/previous link set press '+' / '-'
LEVEL 1 PARAMETERS
------------------
LEVEL1 PARMS BOARD1 BOARD2 BOARD3 BOARD4
INTERFACE DS1 DS1 DS1 DS1
TYPE SS7 SS7 SS7 SS7
LINK 1 2 3 4
BAUD RATE 56 kbps 56 kbps 56 kbps 56 kbps
DATA/CLOCK NORMAL NORMAL NORMAL NORMAL
BRIDGE/TERM TERMIN. TERMIN. TERMIN. TERMIN.
TIME SRC(LNK) 1 2 3 4
DATA SRC(LMK) 1 2 3 4
LINE CODE B82S B82S B82S B82S
EQUAL. 0-131 0-131 0-131 0-131
FRAMING EFS EFS EFS EFS
RX Timeslot: 1 1 1 1 (Corr. channel used on omni)
TX Timeslot: 1 1 1 1 (Corr. channel used on omni)
LOCAL/LOOP: LOOP LOOP LOOP LOOP
APPLY & SAVE CONFIG.
Setup for Network redundancy in Spectra
---------------------------------------
- Select CONFIGURE -> SS7 -> LEVEL3 PARAMETERS -> NETWORK CONFIGURATION.
SP/STP
---
Signaling Transfer Point MSC : 10-10-1
Point code (Network redundancy): 10-10-10
Routes (LS master, LS slave): LS3, LS1
Signaling Transfer Point MSC: 10-10-2
Point code (Network redundancy): 10-10-10
Routes (LS master, LS slave): LS4, LS2
Primary Master: Link set to TO7
Redundant Slave: Link set to TO8
If the Primary node fails the traffic should switch to the Redundant node.
The defined Network Config. should look as follows when it is finished:
Tester Network
------ -------
SP1 Routing
10-10-1 A SP1 LS1 STP 226-555-47 Point code Routes
LS3 STP 226-555-48 10-10-10 LS3, LS1
SP2 Routing
10-10-2 A SP2 LS2 STP 226-555-47 Point code Routes
LS4 STP 226-555-48 10-10-10 LS4, LS2
(10-10-10 is kind of a virtual Jambala.)
HW SPECTRA
----------
POD1 is for link 1
POD2 is for link 2
POD3 is for link 3
POD4 is for link 4
Figure of the Omni and Spectra setup for to7 and to8
----------------------------------------------------
======================== ========================
| to7 | | to8 |
| === | | === |
| Pointcode: | | Pointcode: |
| 226-255-47 | | 226-255-48 |
| | | |
| --------- --------- | | --------- --------- |
| | SS7:1 | | SS7:2 | | | | SS7:1 | | SS7:2 | |
======================== ========================
| \ / |
LS1 | LS2 \ LS3 / LS4 |
RS10-10-1 | RS10-10-2 \ RS10-10-3 / RS10-10-3 |
SLC0 | SLC0 \ SLC0 / SLC0 |
| \ / |
| \ / |
| \/ |
| / \ |
| / \ |
Ch1 | Ch1 / Ch1 \ Ch1 |
LSET0LK0 | LSET1LK0 / LNK0LS3 \ LNK0LS4 |
LSET0 | LSET1 / LSET3 \ LSET4 |
- - - |- - - - /- - - - - - - -\ - - - -| - - -
| | / \ | |
============== S P E C T R A ==============
| | MSC:1 | ============= | MSC:2 | |
| ===== | Virtual pointcode: | ===== |
| | Pointcode: | 10-10-10 | Pointcode: | |
| 10-10-1 | | 10-10-2 |
| | | | | |
| SP1 | | SP2 |
| ============== ============== |
- - - - - - - - - - - - - - - - - - - - - -
Legend: LS = Linkset (Spectra)
RS = Routeset (Spectra)
SLC = Signaling Link Code
Ch = Channel (Omni)
SP = Signaling Point (Omni)
LSET0LK0 = Link (Omni) (Any name can be used)
LSET1LK0 = Link (Omni) (Any name can be used)
LNK0LS3 = Link (Omni) (Any name can be used)
LNK0LS4 = Link (Omni) (Any name can be used)
LSET = Link Set (Omni)
If further links are connected between e.g. SS7:1 and MSC:1, their respective
SLC number will be SLC1, SLC2, and so on.
Define the items in the following order:
1. Linkset
2. Link
3. Routeset
Locations
---------
============= ============= ============= ============= =============
|TelORB proc| |TelORB proc| |TelORB proc| |TelORB proc| |TelORB proc|
| 1 | | 2 | | 3 | | 4 | | 5 |
| | | | | | | | | |
| Loader | | Loader | |Distributor| |Distributor| |Distributor|
| | | | | (Traffic) | | (Traffic) | | (Traffic) |
============= ============= ============= ============= =============
\ | /
\ | /
(TCP/IP) \ | /
\ | /
\ | /
\ | /
======================= ======================= =========== ===========
| IO processor 1 | | IO processor 2 | | SS7:1 | | SS7:2 |
| ============== | | ============== | | ===== | | ===== |
| | | | | | | |
| OAM (IOR) | | OAM (IOR) | | Omni | | Omni |
| | | | | | | |
| JPA | | JPA | | | | |
| | | | | | | |
| CORBA scripts (IOR) | | CORBA scripts (IOR) | | | | |
| | | | | | | |
| Populator (IOR) | | Populator (IOR) | | | | |
======================= ======================= =========== ===========
Explanations and file locations:
OAM Operation and maintenance (User interface + GUI)
File location: /opt/OAM/
JPA Jambala Protocol Adapter (Slow customer population tool)
File location: /opt/JPA/
CORBA scripts Scripts for the Populator?
File location: /opt/telorb/axe/corba/
Populator Population tool (Fast population tool, sends commands to TelORB)
File location: /opt/Populator/
JNI Jambala Network Interface
At a customer site, the same items as in IO processor 1 is also located in
IO processor 2, but it is OK to just have the items in one of the IO processors,
if no redundancy is required.
How to install JNI, GRA and the SCCPManager on the OMNI stack
-------------------------------------------------------------
The following 2 documents describe how to install the JNI, the GRA and
the SCCPManager on the OMNI stack:
/home/www/root/inside/units/f/dv/document/guidelines/docs/GRA_UG.doc
/home/www/root/inside/units/f/dv/document/guidelines/docs/JNI-UG.doc
The JNI is always needed to run traffic.
The GRA is needed when we want to have geographical redundancy failure
detection.
The SCCPManager is needed when we use a geographical redundancy setup on
the INet.
(Source: E-mail from Marc A Khouzam, 991109)
Interfaces
----------
======= ======= ===================
| JPA | --------> | OAM | --------> | TelORB database |
======= (IOR) ======= (IOR) ===================
^ ^
| |
| (IOR) | (IOR)
| |
================= =============
| CORBA scripts | | Populator |
================= =============
Population
____________ _____ _____ _________
| Population | --> | JPA | --> | OAM | --> | JAMBALA |
|____________| |_____| |_____| |_________|
OAM ping, start and stop (in OAM-shell): /opt/OAM/startup/ on e.g. to8io1
Ping: ./pingOAM.csh (Check if OAM is running)
Start: ./startOAM.csh (Gives the printout "OAM Process started")
(Always stop before start)
Stop: ./stop_osagent.csh
./stopOAM.csh
After starting OAM, check that the start was successful for AEC, guardProfile,
Naming Service, NEC, OMLite and OMServer:
cd logs
less *.log ( Check that all six processes are started according to the
following printouts.
AEC: "All CORBA Objects activated!
All classes loaded!"
Guard: "Starting guarded pgm..."
Naming: "Starting process Naming"
NEC: "All CORBA Objects activated!
All classes loaded!"
OMLite: "LiteIMRSVr ready!"
OMServer: "ACTIVATION: Database is already opened as
READ/WRITE..."
(OSAgent)
(Location Service)
(OTS)
(locserv) )
G = end of file
f = forward in file
b = backward in file
:n = next file
q = quit
Open OAM via local Netscape (e.g. on to8io1):
cat /home/telorb/startGui
/home/telorb/startGui (Run script)
netscape&
Start the Jambala Toolbox...
root
root_password
Login
JPA-commands for population/depopulation (in JPA-shell): /opt/JPA/
Start: ./startJPA.csh 8600 (if "FATAL JPA ERROR" is received, start OAM.)
(if "FATAL JPA ERROR" is received again,
./stop_osagent.csh)
When the following printout is received, the population can be started:
"Wait for connection..."
Start population (in Population-shell): /opt/population/
Start: source looping.csh
Stop: Ctrl-c
Hints:
Two things for OAM. The first is important when you start a new window
to use OAM
Marc
If OAM is having problems with objectstore and can't find it:
setenv OS_ROOTDIR /opt/ODI/ostore
--
To re-add root to the allowed users of OAM after a full boot:
/opt/OAM/omserver/bin/init_oam_database.csh
|
|
|
|
|
|
|
http://uabweb.uab.ericsson.se/inside/units/k/kh/d/dv/document/guidelines/spectra.html
